Estimated time of arrival (ETA) systems and methods

ABSTRACT

A system on a network provides estimated time of arrival information to a client located on the network. The system is adapted to present to the client pages for eliciting a product inquiry including a product number. The system receives the product inquiry, determines estimated time of arrivals for various destinations for at least one in-transit unit having the product number, and transmits to the client the estimated time of arrivals.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computer software systems and, moreparticularly to computer systems for determining the estimated time ofarrival of products.

2. Description of the Related Art

Product availability and shipping costs are key factors in determiningwhether a dealer makes a contemplated purchase order. If a product isnot available because it is out of stock, a dealer may decide to orderanother manufacturer's product. Even if the product is available, adealer may still decide to order a product from another manufacturer ifshipping costs are too high.

Manufacturers use various storage warehouses which are strategicallylocated to lower freight costs to the dealers. Each dealer is assigned adefault warehouse, but has the option to order from secondary (i.e.,alternate) warehouses as well. However, the default warehouse istypically located closer to the dealer than the secondary warehouses.Thus when ordering from a secondary warehouse, the dealer usuallyexpects to pay a higher freight cost.

Sometimes the default warehouse is out of stock and the dealer has noother choice except to order from the secondary warehouse or orderanother product—perhaps one made by another manufacturer. If time is ofthe essence and the buyer is not willing to pay the extra freight cost,the manufacturer may end up loosing the sale. Dealers also becomeannoyed when they must speak to a manufacturer's representative to findout what order options are available. In addition, disputes can ariseafter a dealer orders a product on a rush basis without realizing thatfreight charges will be higher because the product was available onlyfrom the secondary warehouse. Without having control as to whichwarehouse the product is being shipped from, the dealer is usuallyunpleasantly surprised by the extra freight cost. In any event, if amanufacturer's products are consistently out of stock or not availablefrom the default warehouse, the customer will be inconvenienced anddissatisfied with the manufacturer's ordering services.

An early conventional business model involves replying back to arequester with an estimated availability date either over the phone orthrough e-mail communication. In such models, estimated time of arrivalcalculations were performed manually by checking in-transit containerschedules and estimated time of arrival time tables generated usinghistorical data. It was very inefficient to determine which warehouse iscapable of supplying the merchandise and to calculate freight costdifferences manually. Networked computer systems have begun to improvethese inefficiencies.

Data interchange systems are well known. These systems interchange datarelated to a business transaction such as order entry data. One wellknown data interchange system uses the Electronic Data Interchange (EDI)method of transferring business communications between dealers andsuppliers. EDI systems transfer data in a structured manner, usingagreed message standards, from one computer system to another. Otherorder entry systems having different data interchange formats can beused to generate business communications as well. Proprietary networkaccess systems, for instance, allow remote dealers (or intranet orextranet users) to access ordering systems using different specializedinterfaces and exchange methods.

U.S. Pat. No. 6,609,108 purports to provide an on-line method and systemin which a consumer is provided real-time information, prior to theplacement of an order or purchase by the consumer, regarding theavailability and status of a configured product in relation to theproduct's manufacturing and delivery process or“pipeline”. The productdelivery time to a consumer is reduced by locating and“tagging” anavailable product at various stages in a product. pipeline, includingscheduled and unscheduled order banks, final assembly, in-plantinventory, in-transit stock and dealer inventory. Real-time pricing andcomparison data is provided for individual product features or options.

Tracking systems are also well developed, including those usingsatellites and other electronic technology, to obtain real-time data onin-transit locations of containers. Inventory accounting and managementsystems that ascertain the contents of very large warehouses to a highlevel of detail at any point in time are also well developed. An exampleof a container and inventory monitoring method and system is disclosedin U.S. Pat. No. 6,148,291.

Transport carriers, such as Federal Express®, have the ability toreroute shipments when authorized by the sender. However, specialhandling charges are generally billed to the customer for each reroutedpackage. The customer may also decide to stop the shipment before itgets to a final destination. In other words, instead of rerouting thepackage, the package is held at a particular destination along the way.This requires that someone with authority call the carrier company withpertinent information at hand. A transport carrier can also divert anyshipments (including by using other carriers) to facilitate itsdelivery.

In addition, the management of order reception, processing, procurement,logistics, warehouse functions and tracking of products has beencomputerized and integrated. U.S. Pat. No. 5,987,423 discloses an objectoriented programming (OOP) framework including an order managementmechanism that tracks sales orders received and matches them towarehouse inventory, a sales order mechanism that processes sales ordersand a purchase order mechanism that processes purchase orders. The '423patent further discloses interfacing underlying business functions suchas accounting, warehouse management and sales and purchase ordertracking.

Despite the promise of computerized and integrated order processingsystems, such current commerce software is typically of limitedcapability. The cost of inventory is an area of constant concern tobusinesses. Too much inventory not only eats up the working capital of acompany and creates cash flow problems, but also requires additionalspace and people to manage it. The opposite problem of too littleinventory can cause production delays and poor customer service. Nosystem has heretofore been described or available that dynamicallyprovides estimated time of arrival information and/or freight costinformation based on constantly changing factors such as currentshipment status or diversion options. Nor is there a system thatincludes an automated system which diverts containers based on differentfactors, such as delayed shipment delivery time, urgent requests,warehouse stock, vendor status, and contract requirements. In addition,current systems do not provide the information dealers want to makeinformed and economical ordering decisions.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide an effective systemin which dealer can get real time estimated time of arrival of aproduct. It is also an object of the present invention to provide thedealer with the ability to choose from alternate destinations and withestimated freight cost information. Another object of the presentinvention is to provide in-transit product diversion for providingoptimum product allocation. Yet another object of the present inventionis to provide the ability to divert shipments due to factors that maychange while the product is in-transit.

In accordance with one embodiment of the present invention, a system ona network provides estimated time of arrival information to a clientlocated on the network. The system is adapted to present to the clientpages for eliciting a product inquiry including a product number. Thesystem receives the product inquiry, determines estimated time ofarrivals for various destinations for at least one in-transit unithaving the product number. The system can also transmit to the clientthe estimated time of arrivals.

In accordance with another embodiment of the present invention, a systemis provided which is adapted to transmit to a server on a networkproduct inquiry information including a product number. The systemreceives estimated time of arrivals to at least one destination for atleast one in-transit unit having the product number.

In still another embodiment of the present invention there is provided asystem for providing excess freight cost information including excesscosts for ordering from at least one secondary destination. The systemis adapted to present to a client located on the network one or morepages adapted to elicit a product inquiry including a product number andreceive the product inquiry. The system receives from a product weighttable database a corresponding product weight, receives from a dealerlocation database a dealer address, receive from a freight tabledatabase at least one freight cost based on the dealer address, andcalculate at least one difference in freight cost based on theinformation stored in the product weight database, the freight databaseand the dealer location database. The system also transmits to theclient the at least one difference in freight cost.

In yet another embodiment of the present invention, a system located ona network linking the system with a server is provided which is adaptedto transmit to the server product inquiry information including aproduct number and a customer identifier. The system receives at leastone difference in freight cost for ordering from at least one secondarydestination based on the product inquiry.

In yet another embodiment of the present invention, a system on anetwork automatically diverts one of a plurality of in-transit unitshaving a product number to one of a plurality of destinations. Thesystem is adapted to determine an estimated time of arrival to each ofthe plurality of destinations for the plurality of in-transit units. Thesystem is further adapted to determine a diversion plan based on saleshistory information for each of the plurality of warehouses, currentinventory information for each of the destinations and in-transitinformation, the current inventory information including back-orderdata, the in-transit information including the location of the pluralityof in-transit units. Based on the diversion plan, the system diverts theone unit to one of the destinations.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram for implementing the methods andsystems of the present invention.

FIG. 2 is an illustration of an initial order entry screen which allowsentry of basic account and shipping information.

FIG. 3 is an illustration of an order details screen which allows entryof product supply order information.

FIG. 4 is an illustration of an order availability screen for providingavailability and cost information, and for hyperlinking to analternative warehouse information and selection screen.

FIG. 5 is an exemplary illustration of an estimated time of arrivalinformation and order option screen, for viewing and selecting defaultand alternate warehouse delivery order options.

FIG. 6 is an illustration of possible delivery routes a manufacturer'sproduct may travel while in-transit from a manufacturing plant to awarehouse.

FIG. 7A is an exemplary illustration of an ETA inquiry screen forviewing warehouse current and projected inventory and backorder statusfor a particular product in accordance with the present invention.

FIG. 7B is an exemplary illustration of an ETA inquiry screen forviewing more detailed ETA and warehouse allocation information for aparticular product in accordance with the present invention.

FIG. 7C is an exemplary illustration of an ETA information inquiryscreen for showing information about potential in-transit containerdiversion scenarios for a particular product.

FIG. 7D is an exemplary illustration of a warehouse information anddiversion entry screen for viewing warehouse historical and currentsales and inventory allocation and for entering diversion instructionsvia a manual operation in accordance with the present invention.

FIG. 7E is a lead time table showing how long it takes various carrierservices to deliver shipments.

FIG. 8 is a detailed block diagram of an embodiment of the diversioncontrol system in accordance with the present invention.

FIG. 9 is a detailed block diagram of an embodiment of the freight costcalculation system in accordance with the present invention.

FIG. 10 is a detailed block diagram illustrating an overview of the dataflow for implementing the methods and systems of the present invention.

FIG. 11 is a detailed block diagram of an embodiment of the presentinvention in accordance with the data flow diagram illustrated in FIG.10.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The terms “user”, “operator”, “customer”, “consumer”, “dealer”, “vendor”and the like mean any person who may benefit from the present invention.

“Manufacturer” means the person or entity manufacturing and sellingproducts.

“Product” means any product under the sun. The words “item” and “unit”are used to identify one product having a product number.

“Computer” may refer to a single computer or to a system of interactingcomputers. Generally speaking, a computer is a combination of a hardwaresystem, a software operating system and perhaps one or more softwareapplication programs. Examples of computers include, without limitation,IBM-type personal computers (PCs) having an operating system such asDOS, Windows, OX/2 or Linux; Macintosh computers; hardware having aJAVA-OS operating system; graphical work stations, such as SunMicrosystems and Silicon Graphics Workstations having a UNIX operatingsystem; PalmPilots; and PilotPCs.

“Network” means a connection between any two or more computers, whichpermits the transmission of data. One example of a network is theInternet.

“Client/server” architecture is a network architecture in which eachcomputer or process on the network is either a “client” or a “server”. A“server” is a computer or device on a network that manages networkresources and is operable to receive requests from third parties on thenetwork and respond to those requests. Requests are sent to a server bya “client”, typically an application that runs on a personal computer orworkstation and relies on the server to perform some operations.

“Web page” means any documents written in mark-up language including,but not limited to, HTML (hypertext mark-up language) or VRML (virtualreality modeling language), dynamic HTML, XML (extended mark-uplanguage) or related computer languages thereof, as well as to anycollection of such documents reachable through one specific Internetaddress or at one specific site on the World Wide Web (“Web”), or anydocument obtainable through a particular URL (Uniform Resource Locator).

“Web site” means at least one Web page, and preferably a plurality ofWeb pages, virtually connected to form a coherent group.

“Web browser” means any client software program running on a computerwhich can display text, graphics, or both, from Web pages on Web sites.Examples of Web browsers include, without limitation, Netscape Navigatorand Microsoft Internet Explorer.

The phrase “display a Web page” includes all actions necessary to renderat least a portion of the information on the Web page available to thecomputer user. As such, the phrase includes, but is not limited to, thestatic visual display of static graphical information, the audibleproduction of audio information, the animated visual display ofanimation and the visual display of video stream data.

“Web server” is a server which is capable of serving at least one Webpage to a Web browser.

“Default warehouse” means the warehouse assigned to a dealer as itsprimary warehouse from which it is to receive a product.

“Alternate warehouse” means a warehouse not assigned to a dealer butwhich is a secondary source from which it may choose to receive aproduct.

“Allocate” means to apportion for a specific purpose or to particularpersons or things.

“Back-order” means the warehouse is temporarily out of stock on aparticular item ordered.

“Container” means something that holds goods. In the presentspecification, a container can hold all or a portion of the contentsoriginally loaded into it.

“Logistics” means any aspect of business dealing with the procurement,maintenance, allocation, transportation and delivery of manufacturerproducts.

“Divert” to turn from one course or use to another.

“Diversion” means the act or an instance of diverting from a course,activity, or use.

“ETA” means estimated time of arrival.

“Manual operation” means a step performed or done by hand and not by aprocessor. An example of a manual operation includes, but is not limitedto, inputting data to be used by a processor, as opposed to theprocessor accessing a database having pre-stored data.

For the present invention, a software application could be written insubstantially any suitable programming language, which could easily beselected by one of ordinary skill in the art. The programming languagechosen should be compatible with the computer by which the softwareapplication is executed, and in particular with the operating system ofthat computer. Examples of suitable programming languages include, butare not limited to, C, C++, CGI, Java and Java Scripts. Furthermore, thefunctions of the present invention, when described as a series of stepsfor a method, could be implemented as a series of software instructions,for being operated by a data processor, such that the present inventioncould be implemented as software, firmware or hardware, or a combinationthereof.

The client computers discussed below each preferably includecommunications hardware and an operating system with graphical userinterface (GUI) functionality to allow for interface with the Internet.Each client computer preferably has graphical Web browser software, suchas Netscape Navigator or Microsoft Internet Explorer, loaded thereonoperable to read and send Hypertext Markup Language (HTML) forms fromand to a Hypertext Transfer Protocol (HTTP) server on the Web. Theclient computers preferably is operable to act as a virtual machine torun Java applets, or the like, downloaded by the browser from theserver. The server preferably includes hardware, HTTP compliantsoftware, an operating system and common gateway interface (CGI)software for interfacing with input queries and sources of data. Thecommunication between all clients and servers is preferably via a widearea network (or WAN, not shown), such as for example the Internet.

One basic system configuration for implementing the present invention isdepicted in FIG. 1. Order entry client 1 communicates business data toETA customer order database 2. Order entry client 1 can consist ofvarious order entry systems 1 c, 1 d, 1 e each using a different datainterchange method. One customer may, for example, use the well knowndata EDI interchange method 1 a, and another might use a proprietaryextranet interchange method 1 b to access the network. The Order entryscreen server 4 receives data from different sources and communicatesthe formatted data to the ETA Customer Order database 2 so that thedifferent Order entry systems 1 c, 1 d, 1 e, (collectively Order entryclient 1) communicate properly with the ETA Customer Order database 2and the rest of the system.

Preferably, but not necessarily, the ETA Customer Order database 2 ismaintained on a database server, and comprises a relational databasemanagement system (RDBMS), in which stored information is arranged intables of rows and columns, related to one another by predeterminedfunctions, and can be accessed by database query protocols, such as forexample the Structured Query Language (SQL). Also, the ETA CustomerOrder database 2 may in actuality be several databases, such as forexample an extranet order database or EDI order database, each of whichis maintained on a separate database server.

The ETA Customer Order database 2 communicates customer orders to theETA calculation server 3. ETA calculation server 3 determines estimatedtime of arrival information for allocated shipments as well asunallocated product shipments. Unallocated product shipments areshipments which contain products which have not yet been designated afinal warehouse destination. Allocated product shipments have beendesignated to a particular warehouse. Reserved products are allocatedproducts further designated to a customer. The results are communicatedto ETA Result database 5 and subsequently fed to the Order entry screenserver 4 for further formatting, as described above.

In-transit source 6 collects data related to in-transit cargo andshipments and stores this data in the ETA Delivery Order database 10.Import invoice source 6 a transmits information including the identifierfor the designated final destination warehouse for a particularshipment. In-transit warehouse transfer source 6 b collects informationon shipments that are in-transit between warehouses including currentlocation. Similarly, domestic shipping source 6 c collects informationon shipments that are in-transit to dealers. Other information thein-transit sources 6 a, 6 b, 6 c, can upload to the ETA Delivery Orderdatabase 10 includes invoice information, destination, vessel name,container information, and estimated time of arrival (if available).Current warehouse in-stock information system 9 is uploaded to a ETADelivery Order database 10 as well. This data is communicated to the ETAcalculation system 3 to use in calculating ETAs of shipments.

Information from the warehouses inventory source 9 and in-transit source6 can be uploaded to the ETA result database one or more times a day orcan be uploaded in real time as inventory or in-transit shipmentinformation is updated. The update information can be received directlyfrom the shipper (e.g., cargo vessel, trucking company), or by usingtables generated using historical data. If delivery order uploads fromthe ETA Delivery Order database 10 are performed only once, in themorning for instance, then during the daytime product availability andETA information is based on the data stored as of that time.

Diversion control server 7 controls the allocation of current inventoryand in-transit shipments and diverts any, as necessary. This server 7determines whether an in-transit shipment should be diverted, andcommunicates its actions to the ETA Delivery Order database 10 so thatthe ETA Calculation server 3 is made aware of any diversions, which mayaffect shipment ETA. In addition, server 7 can determine where currentin-stock inventory should be shipped. Diversion control server 7 isdescribed in more detail below with reference to FIG. 8.

The Freight Matrix server 8 communicates to the Order entry screenserver 4 data used to display alternate warehouse ordering options.These options provide a dealer the capability to pull inventory fromother warehouses when there is no inventory at the default warehouse.Freight Matrix server 8 also provides information (via Order entryscreen server 4) including additional freight costs incurred whenordering from alternate warehouses. Freight matrix system 8 is describedin more detail below with reference to FIG. 9.

The integration of the freight matrix, ETA calculation, and diversioncontrol systems not only provide useful information to customers, butalso permit the overall system to optimally allocate shipments. Realtime and accurate available data can be provided at all times through aWeb site. In addition, the information can be delivered to all ofcustomers regardless of any sales channels or order entry methods.Dealers can make educated decisions on what to order armed with theoption to pull from distant available warehouses, review ETAinformation, and have a clear understanding as to what added freightcosts might be incurred. Having diversion capability also allowsinventory balance to be controlled for various warehouses by calculatingthe optimum location and quantity for products while in-transit.

It should be understood, of course, that configurations other than thatillustrated in FIG. 1 are also possible. For example, the Order entryscreen server 4 may communicate directly with the order entry clients 1as opposed to formatting data on a server. Or all communications may bethrough a LAN, or a WAN other than the Internet, or through dedicatedconnections. Other configurations are possible as well.

FIG. 8 is a detailed block diagram of the Diversion Control server 7discussed above with respect to FIG. 1. Current in-transit informationincluding the location of in-transit containers and their correspondinginventory is collected by In Transit Information source 6. Thisinformation is combined with Lead Time Table 90, to provide informationas to how long it will take various carrier services to delivershipments. Lead Time Table 90 can be a database server which can combinethe data received from In Transit Information source 6 with its ownlead-time data and store it into a database. FIG. 7E is an example of alead-time table (or can be viewed as a result of a calculation using alead-time formula) showing how long it takes various carrier services todeliver shipments. The Origin column identifies the port of origin; inthis example can be Japan or China. The Transit Time Formula stores theformula (or logic) for calculating transit times.

As discussed above, formulas can vary greatly. For example, one formulamay take into account such variables as average speed of a vessel,current and predicted weather and time to unload, while another may nottake into account the weather. In addition, data used by the formula canbe received (i.e., input) directly from the vessel carrier or transportservice and thus the present invention need only add that data to itsformula. The precise transit time formula is not important and any suchformula is within the scope of this invention.

In addition, different scenarios, depending on which shipping andtransport services companies are used, are also stored in the lead timetable. In this example, the current transit time it will take acontainer to reach a warehouse is shown in the Current Transit TimeFormula To Warehouse row. Also shown in the Destination column are thetransit times it will take for a container to reach a particulardestination railway station (“RIR”) or warehouse (“W/H”). Here there arefive warehouses, located in five different locations, LA, Dallas,Chicago, Atlanta and NJ. The above provides a snapshot of a fewexemplary scenarios. There can be many more.

In any event, the in-transit information data is combined to a lead-timetable data and communicated to a Diversion Control Table 95. DiversionControl Table 95 can also simply be a database server which holds dataand communicates it to other databases. Alternatively, it can be aserver that processes the combined data and converts it into a formatthat can be used by other servers or databases. The latter is thepreferable.

Sales history for the various warehouses is collected by the SalesHistory source 91 and communicated to the Diversion Control Table 95.Current inventory information collected by the Inventory Informationsource 92 and warehouse back-order information collected by the BackOrder source 93. Data from these sources are also fed to the DiversionControl Table 95. In the preferred embodiment, after collecting all thedata it has received, the Diversion Control Table 95 processes it into aformat that that can be communicated to the ETA Divert Plan server 94.

Based on the results, the Divert Plan server automatically communicatesinstructions to divert containers or change container content. Theseinstructions can, for instance be communicated to the shippingcompanies, loading and unloading docks or anyone else involved inshipping or storing the products.

Diversion Control Table 95 also processes the data into a format thatcan be communicated to the ETA Delivery Order database 10. Order entryclient 1 can then execute a diversion manually.

In addition, ETA Delivery Order database 10 can provide this informationto the ETA Calculation server 3 (shown in FIG. 1). ETA Calculationserver 3 can then use this information to calculate ETAs for anydiversions.

If an in-transit container of products has been diverted, that diversionis recorded by the Diversion Control Table 95 so that the container willnot be allocated again. It may be the case, however, that based uponpriority status, a container may be allocated again to anotherwarehouse. In addition, a diversion control plan may also be transmittedto someone with authority before execution for approval. For example, alogistics department of a manufacturer may wish to approve alldiversions.

Advantageously, the present invention dynamically allocates manufacturerproducts. It may be the case where it would be inefficient to tag a unitfor delivery to a warehouse too early. Or, allocated shipments may bebehind or ahead of schedule requiring that replacement allocations bemade in order to fulfill obligations.

For instance, referring to FIG. 6, it may be the case where two of thesame type of units, one shipped on ship 62 a and the other on ship 62 bhave different arrival ETA dates at port 63. The ship from Japan 62 a isscheduled to arrive at port 63 on Jan. 1, 2004, and the ship from Taiwan62 b is scheduled to arrive at the same port on Jan. 5, 2004. During theoceanic trip, cargo vessel 62 a may be delayed due to inclement weatherand it is determined that it will arrive at port 63 later thanoriginally expected (i.e., Jan. 5, 2004). With the present invention,any portion of the cargo on the other vessel 62 b can be redirected tofulfill delivery order obligations. Thus in this example, if thediversion plan is based on a First-Come-First-Serve model, then thecustomer that ordered this type of unit first, gets the first one toarrive at port 63, even though it was originally allocated to gosomewhere else.

In other words, units on any vessel can be redirected by overriding anyprevious destination warehouse allocation. The dealer does not know thatover the course of a few days different units had been allocated tofulfill a purchase order. All the dealer knows is that a unit having theproduct number he/she ordered arrived on time, and was charged theexpected freight costs. Other factors may dictate cargo allocation aswell. A warehouse with a large backorder of a particular product maytake precedence over one having it in stock. Or, an operator with highpriority status may take precedence and thus redirect shipments.

Each factor used to decide a divert plan can be designated a particularpriority which is then stored into a metrics table. The metrics tablecan then be used to calculate shipping priority. The method in whichshipment priority is calculated can be based on a simple formula, ormore complex decision logic can be used. Neural network logic, forinstance, can be implemented to operate on historical data to determinethe best shipping routing strategy. Neural networks work well with bothcategorical and continuous variables and do not require a linearrelationship between predictor and dependent variables. Some well knownapplications for neural networks are indeed predicting, forecasting,pattern recognition, and/or processing problems, all of which aremultivariate and data intensive.

FIG. 9 is a detailed block diagram of an embodiment of the FreightMatrix server 8 discussed above with respect to FIG. 1. As discussedabove, the inventory from other available warehouses can be pulled whenthere is no inventory at the default warehouse.

Once an order is placed via the Order entry client 1, Freight Matrixserver 108 calculates the freight increase amount based on variousfactors including product weight, freight costs, and the distancebetween a particular warehouse location and a dealer location. Theproduct weights are stored in a Product Weight Table database 100 whichsimply matches a particular item number with its corresponding weight.Freight costs are also calculated based on the distance between aparticular warehouse location and a dealer location. This determinationis made using dealer address information, which can be stored in aDealer Ship to Location Table database 104. Inventory availability comesfrom an Inventory Information database 106. Inventory Informationdatabase 106 can be fed inventory information by the Stock InInformation source 9, discussed above with respect to FIG. 1.

An overview of the shipping process in accordance with the presentinvention is now presented in terms of transport mechanisms. FIG. 6shows the travels a product takes after it leaves a manufacturing plant.

After manufacture, the product units are loaded into shippingcontainers. As shown, container transport vessels 62 a and 62 b ship thecontainers from port 61 a (which may be in one country) and port 61 b(which may be in another country) to a particular port 63 in the UnitedStates. At port 63, the containers are unloaded and then transported toone of five warehouses 65 a-65 e, via rail, truck or air freight. Eachcontainer can be tracked to obtain real-time data on its in-transitlocation. In addition, the contents (i.e., the products) can beascertained to a high level of detail at any point in time. Even if thecontents of a container have changed, the present invention observes thechanges to make correct allocation decisions and estimated time ofarrival and freight cost calculations.

Normally shipping containers departing ports of origin 61 a, 61 b aredesignated final destinations when they depart. However, some are notallocated. Unallocated containers, or “diversion containers”, can beallocated to different final destinations during transportation. Inother words, final destinations (e.g., final destination port orwarehouse) of any diversion containers can be decided at any time beforeunloading commences at the destination port 63.

In the event a container must be diverted (e.g., to fulfill abackorder), it is typically preferable to allocate a diversion containerover an allocated container so as to not disrupt a delivery order.However, sometimes it may more efficient and economical to divert anallocated container to, for instance, fulfill contractual requirements.

Portions of any container, either in the context of diversion containersor allocated containers, can be removed and placed in other containersat any time during transit and assigned a final destination.

The present invention advantageously provides ETA information for anyproduct to any warehouse. As mentioned above, some products areallocated to the warehouses 65 a-65 e at some time before they reachport 63. Those held in diversion containers are not. In addition, any orall of the contents (i.e., the products) of any container can bediverted for various reasons. Still further, all the allocated andunallocated products ETAs are determined and available to DiversionControl server 7. ETA information may even be provided for a productin-transit even though it has not been allocated.

Thus, the present invention advantageously allows a dealer to makepurchase order decisions based not only on what products are availablein its default or alternate warehouses, but also in accordance within-transit shipments anywhere. The present invention saves the customermoney in freight costs by essentially permitting the dealer to placeinventory in the manufacturer's warehouse. The invention also helps themanufacturer manage working capital, creates cash flow and efficientlymanages warehouse inventory at the very least. In addition, the presentinvention improves customer service.

FIGS. 2-5 are exemplary Web pages for data entry and viewing inaccordance with the present invention. FIG. 2 is an illustration of aninitial order entry screen which allows entry of basic account andshipping information. Each purchase order is assigned a purchase ordernumber 20. Common shipping and account information is entered at theappropriate fields 21 a-k, or the Viewed Saved Orders button 22 isselected which allows an operator to view and modify prior saved orders.Alternatively, an Order Upload button 23 is selected to upload orderdata files which have been generated previously using an editor orspreadsheet program. Using a saved order or a previously generated ordersaves time for dealers who order the same, or relatively the same,merchandise often. The operator then selects the. Continue button 24 tocontinue processing the order or selects a Cancel Order button 25 tocancel the order.

FIG. 3 is an illustration of a supply order details screen displayed toan operator if the Continue 24 button was pressed in the above-describedinitial Order screen. Item numbers which have been entered or loaded areshown in the Item number (“#”) column 31 a, and their correspondingdescriptions are displayed in the Description column 31 b. The dealerenters the quantity of items requested in the quantity column 31 d.Using the Ship Complete checkbox 31 e, the dealer can elect whether theitem order should be delivered in one shipment or, if the quantity ofitems selected is not immediately available, whether the items should bedelivered in separate shipments. The Unit Price and total amount foreach item is displayed in the Unit Price 31 f and Amount 31 g columns,respectively, by selecting the Get Price button 32. Alternatively, thisinformation can be updated automatically as data is entered, therebyeliminating the need for a Get Price button 32.

A Catalog button 33 is available to assist the operator in findingparticular products or information about them. The operator can also addor delete item lines by pressing the Add Lines button 34 and DeleteLines button 35, respectively. In addition the operator may customizethe header using the Edit Header button 36. Once the items have beenentered, the order information can be saved by pressing the Save Orderbutton 37. If the operator presses the Continue button 24, the ETAsystem will then proceed to a status screen as shown in FIG. 4.

FIG. 4 is an illustration of an order status screen for providingdefault warehouse availability and cost information, and forhyperlinking to an alternative warehouse information and selectionscreen. This screen displays the information entered by the operator inthe initial order entry screen (FIG. 2) and the order details screen(FIG. 3) described above. As shown in the warehouse (W/H) column 40,this dealer has a contract which designates its default warehouse as theNew Jersey warehouse. The Availability column 41 shows the first item isavailable while the second is not. Additional items can be queried bypressing the Add Items button 42.

The user then has the option to submit the order by pressing the Submitbutton 43, which then proceeds with the request. Alternatively, theoperator has the option to check when the default warehouse will havethe item in stock and view other availability options. This is done byselecting the item that is not in stock. In FIG. 4 this is done byselecting the “No” hyperlink in the Availability column 41 which takesthe operator to another screen, shown in FIG. 5.

FIG. 5 is an exemplary illustration of an estimated time of arrivalinformation and order option screen, for viewing and selecting defaultand alternate warehouse delivery order options. This screen can be apop-up screen (as shown) which extends from the order availabilityscreen discussed above with respect to FIG. 4. Some of the informationis the same as presented on the previous screens (FIGS. 2-4). The restof the screen is divided into two sections, 52 and 54. Section 52displays information related to the dealer's default warehouse andsection 54 displays information related to the dealer's alternate (i.e.,secondary) warehouses.

Quantity columns 55 and 58 show whether the quantity of product unitsrequested by the dealer. However, those columns will show less if lessare available. If the products are not available, the Status columns 41and 56 will identify accordingly. If the default warehouse is out ofstock, a Stock-In Date column 53 will indicate when the next shipment isexpected to arrive. If the requested order is partially available (notshown) the screen would show the quantity of available units in theQuantity column 55 as well as when the remainder will be in stock in theStock-In-Date column 53. Similarly, if the requested order is partiallyavailable (not shown) in the alternate warehouses, the screen would showthe quantity of available units in the Quantity column 58 as well aswhen the remainder will be in stock in a Stock-In-Date column (notshown).

The alternate warehouse section 54 further includes the difference infreight costs corresponding to a particular secondary warehouse, shownin Freight Difference column 57. The freight increases are shown on apercentage basis.

FIG. 7A is an exemplary Web page for viewing warehouse current andprojected inventory and backorder status for a particular product. Theproduct is identified in the Product Number field 77 and it has adescription noted in the Description field 78. Once a product number hasbeen entered, the operator selects the Inquire button 79 to receive thecurrent inventory status for the product.

Each warehouse is designated numerical values as shown in the warehouse(“W/H”) column 80. The corresponding current inventory count for eachwarehouse is tabulated in the INVENTORY column 81. Identified in theINTRANSIT column 82 is the number of units in-transit to the warehouses80. In the BACK ORDER column 83 the number of units on back-order isidentified. Thus, for example, warehouse 22 (in W/H column 80) does nothave product number “6378A0023BA” currently in stock, as indicated byits corresponding INVENTORY column 81. Warehouse 22 is expected toreceive a relatively large shipment of that product, 432 units to beexact, as indicated in INTRANSIT column 82. Warehouse 22 also has aback-order on that particular product of 33 units.

More detailed information on the shipments of a product to a particularwarehouse can be viewed by selecting one of the INTRANSIT column 82hyperlinks (shown as underlined numbers). For example, if an operator isinterested in the information on warehouse 22, “432” under INTRANSITcolumn 82 can be selected. The screen shown in FIG. 7B is thendisplayed.

FIG. 7B is an exemplary Web page for displaying information on warehouse22, particularly relating to its inventory status for a product. Column70 contains three categories of information. One category, designatedsection 70 b, shows the status of the warehouse inventory at aparticular time. In this example, for this particular warehouse,inventory information is for the morning. During the morning thewarehouse had 94 units available, as shown in the quantity (“QTY”)column 72. However, at that time, all 94 units had been allocated, asshown in QTY Allocated column 74.

Another category, designated as section 70 a, shows in delivery order(“DO #”) column 70 that there are five delivery orders to ship theproduct to warehouse 22. In particular there are five containersidentified in Container number column 75, each holding 72 units, asshown in QTY column 72. As shown in QTY Allocated column 74, onecontainer, identified as “NYKU6057975”, has 33 of its 72 units allocatedto that warehouse. This coincides with the back-order of the product onwarehouse 22, discussed above with reference to the BACK ORDER column 83in FIG. 7A. This allows an operator (or server controlling allocationautomatically) to prioritize which shipments should be allocated ordiverted first. The ETA dates to the warehouse are identified inETAWHDATE column 73. Container “NYKU6057975” has been identified ashaving the earliest arrival date to warehouse 22 and has thus units fromthat container have been allocated first.

Section 70 c shows the status of any in-transit shipments betweenwarehouses. This is indicated by the “XFER” designation in theCOINTAINER # and INVOICE # columns. Invoice column 76 shows the invoicenumber for a particular shipment, if available. More details about thistransfer shipment, such as method of shipment, can be found by pressingXFER (not shown).

FIG. 7C is an exemplary Web page for showing information about potentialin-transit container diversion scenarios for a particular product. Aftera particular product is entered into the Product Number field 701, theoperator selects the Inquiry button 703 to view the information. VESSEL# 700 shows all the vessels currently carrying the product. The quantity(“QTY”) column shows how many units of the product each vessel iscarrying. The # OF CONTAINERS column 704 shows how many differentcontainers of that product the vessel is carrying. DUE DATE column 706shows the date by which an allocation must be completed by the operator.This date provides carriers and shippers some time to either repackagethe containers or prepare for transport trucks to pick up the goods atthe port. Accordingly, in this case, an operator can divert a productshipment only before “11/15”.

The ETD column 708 shows the estimated time of departures for thevessels. LA ETA column shows the estimated time of arrival at the LAwarehouse. Delivery information can be confirmed either by the shippingcompany or some other source. If a shipment can be confirmed it shows upin the CONFIRM column 712. Warehouse ETA, number of container andquantity information is also provided for all the other availabledestination warehouses to which a container of products may bedelivered, simply by shifting the screen to the right, as represented by714. With this knowledge, an operator with authority (or serverautomatically) can divert containers as needed. This is accomplished byselecting on the Vessel # hyperlink (e.g., “1X93JF”). The screen shownin FIG. 7D will appear, for example, if vessel “1X93JF” is selected.

FIG. 7D is an exemplary Web page for viewing warehouse historical andcurrent sales and inventory allocation and for entering diversioninstructions via a manual operation in accordance with the presentinvention. Some of the same information from the screen shown in FIG. 7Cis shown in this screen as well. The product number is shown in theProduct Number field 701. The selected vessel number is displayed in theVessel # field 711 a. The Number of containers on this vessel is shownin the # of Containers field 704 a. The total quantity of units isdisplayed in the quantity (“QTY”) field 702 a. The date by which theallocation must be completed is displayed in the Due Date field 706 a.

Additional information is also provided. The total number of productsin-transit on this vessel is shown in the In Transit Total field 720.The estimated time of arrival to a port is shown in the ETA Port field710 a.

Information related to warehouses is provided so that the operator canmake an informed decision. The warehouse number is displayed in thewarehouse (“WH”) column 722. Corresponding sales history information, inthis case for the past six months, is displayed in the Sales History (6month) column 724. The current inventory for each warehouse is displayedin the Current Inventory column 726 and the current back order on thewarehouses is displayed in the Current Back Order (“B/O”) column 728.

An operator diverts containers on the vessel to particular warehouses byentering the quantity of containers to divert in the Diversion # ofContainer field column 730. This column also shows how many units eachcontainer holds. For the operator's convenience, a suggested quantity ofunits to ship is displayed in the Suggested Diversion Plan column 732.This information is determined based on historical data or otherinformation. The particular formula or logic to make the determinationmay vary.

The Approve button 737 is selected to begin processing the entered data.The ETA Replied column 734 indicates the quantity product units thathave already been reported as allocated to customers. ETA column 736indicates the estimated time of delivery to the warehouses. Preferablythe ETA dates displayed in ETA column 736 in FIG. 7D are the same as theETA information shown in column 710 and the other warehouse ETAinformation columns (not shown) in the ETA information inquiry screenshown in FIG. 7C. The dates may be different however, if a shipping orlocal transport company has not confirmed delivery.

It may be the case that the oceanic shipping company has confirmedarrival to a destination port, but the local shipping company (e.g., atrucking or railroad company) cannot. In this event, the ETA informationshown to the operator in FIG. 7C is based on historical data and assumesthe local shipping company will be on time. If all the pertinent data isavailable and current, ETA data displayed on the screens illustrated inFIGS. 7C and 7D will be the same.

Allocation can be automatic, without the need for manual operationsbased on the suggested diversion plan or any data used to calculate thesuggested diversion plan. For instance, diversion can be automaticallydetermined based on the current back orders on the warehouses, theircurrent inventory, sales history or the like.

FIGS. 10 and 11 are detailed block diagrams of an embodiment of thepresent invention. FIG. 10 shows the data flow and FIG. 11 illustrates asystem diagram corresponding to FIG. 10. Any reference to time is merelyexemplary and each data transfer interval can be reduced to real timeupdates or performed periodically. Preferably real time data is used.However, it may be the case that certain information is not available inreal time fashion. In such a situation, the present invention can usethe most recent information available which has been stored in adatabase.

As shown in FIG. 10, three types of order entry client systems are used,an extranet client 235, an EDI client 230, and a proprietary client 225.Each of these clients has an order entry terminal for entering orders,235 a, 230 a and 225 a. As shown, the extranet order terminal 235 a canreceive default warehouse and availability information and proprietaryorder terminal 225 a can send order requests and receive stock-innotifications for orders. However, EDI client 230 can only enter orders.More generally, all operators may not have permission to perform allfunctions available on the system, since, for example dealers need notknow about certain details such as shipping details, e.g., vessel numberor container number, while other operators, for instance those workingin logistics or procurement do. In addition, manufacturers may want tokeep confidential certain information such as cargo location, customerpriority status, shipping company information, freight rates, and thelike. Dealers typically need only know when a particular product willbecome available and for how much.

Data (except for the proprietary client 225 data) is loaded into acustomer order table database 250. The proprietary order entry system225 loads data into its own database and then directly into an ETAcustomer order database 260. In addition, orders can be placedinternally via a terminal attached to the customer order table database.

The logistics database 240 includes databases for storing importinvoices, domestic purchase orders, and current inventory. Invoices aregenerated by the manufacturer 200 and transmitted to the import invoicesource 205 a. The invoice data contains information such as vesselnumber, quantity of shipments, number of containers, estimated time ofdeparture, estimated time of arrival to port, ETA to a particularwarehouse, the number of containers being delivered to a particularwarehouse and the total number of warehouses requiring delivery. Inaddition, the invoice may contain a due-date for which any allocationmust be completed, for example for diversion containers. Thus importinvoices may or may not be allocated.

Similarly, domestic purchase order information is received by thedomestic purchase order source 205 b. Generally, purchase orders are fora particular customer, but it is possible that during an in-transitdelivery an order is canceled. In this case it may be optimal to deliverthe item to another warehouse or keep it on the transport vehicle untilit can be allocated. Similarly inter-warehouse. transfer information isretrieved by the warehouse transfers source 205 c. The data from allthree in-transit sources (i.e., import invoice 205 a, domestic purchaseorders 205 b and warehouse transfers 205 c) is fed into the logisticsdatabase.

The logistics databases 240 a, 240 b and 240 c store all the in-transitand current stock information. All the stock and in-transit shipmentinformation is extracted by the ETA server 220.

Shipping status database 210 receives ETA updates from the shippingcompanies. A copy of the invoices are provided to the shipping companyso that it can match up its cargo vessels with the invoices and updatethe ETA data, as shown in block 210. The shipping company can thentransmit corresponding ETA data to the ETA delivery order database 220.Data from the ETA delivery order database 220 and ETA customer orderdatabase 260 is then processed by the allocation processor 255 asdiscussed above.

Diversion control can be performed by the server running the ETAdelivery order database 220 as discussed above with respect to FIG. 8.Thus, as shown, both diversion control and allocation can be performedbased on delivery order and customer order data.

Block 270 shows an automatic request to reserve product units to currentcustomer backorders. Here, the customer orders are paired up withcurrent in stock data. As units become available, they are delivered tofill the backorders.

ETA and order status inquiries can be made using the wholesale intranetapplication 245, allowing an operator to view the status of all theorders and allocations including diversion container details.

FIG. 11 illustrates the computer network system for performing anembodiment in accordance with the present invention. In-transit data iscollected by invoice source 205 a, domestic purchase order source 205 b,and warehouse transfer source 205 c. The data collected by thesesources, including allocated and unallocated (i.e., diversion container)shipment data, are fed into the logistics processor 240 databases, andthen transmitted and stored in the delivery order database, ETA_DO,located in the ETA server system. Current inventory data is fed to aStock database from a stock-in data source 205 d. The Stock databasedata feeds into the ETA_DO database as well. In addition, data relatedto shipping status, provided by the shipping status source 210, is alsostored in the ETA_DO database. Shipping status source 210 provides thelocation status for in-transit shipments. The origin of this data canreceived directly from the shipping company. In some cases the shippingcompany may also require a copy of an invoice to provide information oncorresponding shipments. If so, a request for necessary invoiceinformation can be requested to the logistics processor, which respondsby feeding the relevant invoice, purchase order, or other transferrelated information to the shipping status source 210.

The data from the logistics and current inventory databases, as well asthe shipping company status data can be collected in the ETA_DO databaseonce a day, or more frequently. Preferably, this data is collected inreal time. However, it may be the case that a data source (e.g., such asthe shipping company status source 210) is out of service or cannot meeta real time update requirement. In these cases, the last availableupdate is used. As shown in FIG. 11 much of the data in this example istransmitted once a day, as indicated by the “Once” blocks. However, anyone of those blocks can be exchanged with a “Realtime” block indicatinga source can transmit data to its corresponding database as soon as itis available. Processing can occur immediately thereafter.

The automatic allocation processor 220 a and manual allocation processor220 b operate on the data stored in the ETA_DO database. Theseprocessors also operate on the data stored in the customer orderdatabase, ETA_CO, which collects all the customer orders from theextranet, EDI and proprietary order systems, 235, 230 and 225,respectively. The results of the processors 220 a and 220 b operationsare subsequently stored in the ETA_DOCO database. As discussed above,the allocation processors can process the data according to any logicformula.

Diversion control is processed by Diversion Control processor 220 c asdiscussed above with respect to FIGS. 8 and 10. This processor can bepart of the same server running the ETA delivery order database ETA_DO.

The ETA—DOCO can be referenced by a variety of applications. Order entryterminals 235 a, 230 a, 225 a and internal wholesale intranetapplication terminal 245 can reference the data to view ETA times andstatus. And, as mentioned above, those systems with proper authority,can then place orders, make diversions and view costs.

Block 270 links the current inventory status (stored in the Stockdatabase) with the Extranet and EDI order entries and reserves ordereditems for allocation to the requester. Extranet and EDI orders can alsobe reserved by the automatic or manual allocation processors 220 a and220 b, respectively, as is done for the proprietary order system 225customer orders.

The ETA processor 220 designates each item in-transit as allocated orunallocated and can designate whether allocated items can bere-allocated. Placing a code in the corresponding item record allows theETA server 220 to filter the logistics data. An example of what a user(or automatic processor) sees is illustrated in the example shown inFIG. 7B. As shown in column 74 of FIG. 7B, thirty-three units areallocated to warehouse 22 to fulfill a backorder. The ETA processorcoded the item records for thirty-three items as allocated so that thoseunits are re-allocated last. If an earlier shipment of unallocated unitshaving the same model units is expected an exchange can occur, changingthe filter codes and causing the previously allocated items to becomeunallocated or reallocated to a different final destination.

While the invention has been described with reference to the structuresdisclosed herein, it is not confined to the details set forth and thisapplication is intended to cover such modifications or changes as maycome within the purposes of the improvements or the scope of thefollowing claims.

1. A system on a network, for providing estimated time of arrivalinformation to a client located on the network, the system being adaptedto: present to the client one or more pages adapted to elicit a productinquiry including a product number; receive the product inquiry;determine a plurality of estimated time of arrivals to a plurality ofdestinations for at least one in-transit unit having the product number;and transmit to the client the estimated time of arrivals.
 2. A systemaccording to claim 1 further adapted to: transmit to the clientdiversion recommendation information including recommended quantity ofunits of the product number to divert to at least one of thedestinations, the recommendation information being based on inventoryinformation and in-transit information, the current inventoryinformation including sales history and back-order data for the at leastone destination, and the in-transit information including a location foreach of the at least one in-transit unit.
 3. A system according to claim1 further adapted to: present to the client one or more pages adapted toelicit from the client a product diversion request including a shippingcarrier identifier, a product number, a quantity number, and adestination identifier; receive the product diversion request; anddivert one of the at least one in-transit units to a final destinationcorresponding to the destination identifier.
 4. A system according toclaim 3, wherein the system diverts one of the at least one in-transitunits based on the results of a diversion planning processor adapted toprocess inventory information and in-transit information, the currentinventory information including sales history for at least one of thedestinations and back-order data at least one of the destinations, andthe in-transit information the location of at least one transportationvehicles carrying at least one of the in-transit units.
 5. A systemaccording to claim 3 further adapted to: transmit to the clientacknowledgement information including the product number and a quantityof units of the product number diverted to the final destination.
 6. Asystem according to claim 3 further adapted to: communicate to ashipping carrier a diversion instruction to divert one of the in-transitunits to the final destination, the diversion instruction including thedestination identifier and a container identifier including enoughinformation to locate the product on a transportation vehicle of theshipping carrier.
 7. A system according to claim 6, wherein thetransportation vehicle is a cargo vessel.
 8. A system according to claim6, wherein the transportation vehicle is a railroad train.
 9. A systemaccording to claim 6, wherein the transportation vehicle is a landtransport vehicle.
 10. A system according to claim 3, wherein thein-transit unit has not been allocated to any one of the destinations.11. A system according to claim 3, wherein the in-transit unit waspreviously allocated to one of the destinations.
 12. A system located ona network linking the system with a server on the network, the systembeing adapted to: transmit to the server product inquiry informationincluding a product number; and receive a plurality of estimated time ofarrivals to a plurality of destinations for at least one in-transit unithaving the product number.
 13. A system according to claim 12 furtheradapted to: transmit to the server a diversion request including ashipping carrier identifier, a product number, a quantity number, and adestination identifier; and receive an acknowledgement from the serverthat it has diverted one of the at least one in-transit units to a finaldestination corresponding to the destination identifier.
 14. A systemaccording to claim 12 further adapted to: transmit to the server aproduct purchase order including a product number, a quantity number,and a customer identifier; and receive an acknowledgement from theserver that the product order has been accepted, wherein the serverdiverts one of the at least one in-transit units of that product numberto a final destination based on the customer identifier.
 15. A system ona network, for providing excess freight cost information includingexcess costs for ordering from at least one secondary destination, theserver being adapted to: present to a client located on the network oneor more pages adapted to elicit a product inquiry including a productnumber; receive the product inquiry; receive from a product weight tabledatabase a corresponding product weight; receive from a dealer locationdatabase a dealer address; receive from a freight table database atleast one freight cost based on the dealer address; calculate at leastone difference in freight cost based on the information stored in theproduct weight database, the freight database and the dealer locationdatabase; and transmit to the client the at least one difference infreight cost.
 16. A system located on a network linking the system witha server, and being adapted to: transmit to the server product inquiryinformation including a product number and a customer identifier; andreceive at least one difference in freight cost for ordering from atleast one secondary destination.
 17. A system on a network, forautomatically diverting one of a plurality of in-transit units having aproduct number to one of a plurality of destinations, the system beingadapted to: determine an estimated time of arrival to each of theplurality of destinations for the plurality of in-transit units;determine a diversion plan based on sales history information for eachof the plurality of destinations, current inventory information for eachof the destinations and in-transit information, the current inventoryinformation including back-order data, and the in-transit informationincluding the location of the plurality of in-transit units; anddiverting the one unit to one of the destinations based on the diversionplan.
 18. A system on a network according to claim 17, being furtheradapted to: communicate to a shipping carrier a diversion instruction todivert the one unit to one of the destinations, the diversioninstruction including a destination identifier corresponding to the onedestination based on the diversion plan and a container identifierincluding enough information to locate the one unit on a transportationvehicle of the shipping carrier.
 19. A system according to claim 18,wherein the transportation vehicle is a cargo vessel.
 20. A systemaccording to claim 18, wherein the transportation vehicle is a railroadtrain.
 21. A system according to claim 18, wherein the transportationvehicle is a land transport vehicle.
 22. A system according to claim 18,wherein the one unit has not been allocated to any one of thedestinations.
 23. A system according to claim 18, wherein the one unitwas previously allocated to one of the destinations.
 24. A method ofproviding estimated time of arrival information to a client located onthe network, comprising the steps of: presenting to the client one ormore pages adapted to elicit a product inquiry including a productnumber; receiving the product inquiry; determining a plurality ofestimated time of arrivals to a plurality of destinations for at leastone in-transit unit having the product number; and transmitting to theclient the estimated time of arrivals.
 25. A method as set forth inclaim 24, further comprising the step of: transmitting to the clientdiversion recommendation information including recommended quantity ofunits of the product number to divert to at least one of thedestinations, the recommendation information being based on inventoryinformation and in-transit information, the current inventoryinformation including sales history and back-order data for the at leastone destination, and the in-transit information including a location foreach of the at least one in-transit unit.
 26. A method as set forth inclaim 24, further comprising the steps of: presenting to the client oneor more pages adapted to elicit from the client a product diversionrequest including a shipping carrier identifier, a product number, aquantity number, and a destination identifier; receiving the productdiversion request; and diverting one of the at least one in-transitunits to a final destination corresponding to the destinationidentifier.
 27. A method as set forth in claim 26, further comprisingthe step of: diverting one of the at least one in-transit units based onthe results of a diversion planning processor adapted to processinventory information and in-transit information, the current inventoryinformation including sales history for at least one of the destinationsand back-order data on at least one of the destinations, and thein-transit information the location of at least one transportationvehicles carrying at least one of the in-transit units.
 28. A method asset forth in claim 26, further comprising the step of: transmitting tothe client acknowledgement information including the product number anda quantity of units of the product number diverted to the finaldestination.
 29. A method as set forth in claim 26, further comprisingthe step of: communicating to a shipping carrier a diversion instructionto divert one of the in-transit units to the final destination, thediversion instruction including the destination identifier and acontainer identifier including enough information to locate the producton a transportation vehicle of the shipping carrier.
 30. A method as setforth in claim 29, wherein the transportation vehicle is a cargo vessel.31. A method as set forth in claim 29, wherein the transportationvehicle is a railroad train.
 32. A method as set forth in claim 29,wherein the transportation vehicle is a land transport vehicle.
 33. Amethod as set forth in claim 26, wherein the one unit has not beenallocated to any one of the destinations.
 34. A method as set forth inclaim 26, wherein the one unit was previously allocated to one of thedestinations.
 35. A method of obtaining estimated time of arrivals froma server on a network, the method comprising the steps of: transmittingto the server product inquiry information including a product number;and receiving a plurality of estimated time of arrivals to a pluralityof destinations for at least one in-transit unit having the productnumber.
 36. A method as set forth in claim 35, further comprising thesteps of: transmitting to the server a diversion request including ashipping carrier identifier, a product number, a quantity number, and adestination identifier; and receiving an acknowledgement from the serverthat it has diverted one of the at least one in-transit units to a finaldestination corresponding to the destination identifier.
 37. A method asset forth in claim 35, further comprising the steps of: transmitting tothe server a product purchase order including a product number, aquantity number, and a customer identifier; and receiving anacknowledgement from the server that the product order has beenaccepted, wherein the server diverts one of the at least one in-transitunits of that product number to a final destination based on thecustomer identifier.
 38. A method of providing excess freight costinformation including excess costs for ordering from at least onesecondary warehouse, the method comprising the steps of: presenting to aclient located on a network one or more pages adapted to elicit aproduct inquiry including a product number; receiving the productinquiry; receiving from a product weight table database a correspondingproduct weight; receiving from a dealer location database a dealeraddress; receiving from a freight table database at least one freightcost based on the dealer address; calculating at least one difference infreight cost based on the information stored in the product weightdatabase, the freight database and the dealer location database; andtransmitting to the client the at least one difference in freight cost.39. A method of obtaining excess freight cost information includingexcess costs for ordering from at least one secondary destination from aserver located on a network, the method comprising the steps of:transmitting to a server product inquiry information including a productnumber and a customer identifier; and receiving at least one differencein freight cost for ordering from at least one secondary destination.40. A method of automatically diverting one of a plurality of in-transitunits having a product number to one of a plurality of destinations, themethod comprising the steps of: determining an estimated time of arrivalto each of the plurality of destinations for the plurality of in-transitunits; determining a diversion plan based on sales history informationfor each of the plurality of destinations, current inventory informationfor each of the warehouses and in-transit information, the currentinventory information including back-order data, and the in-transitinformation including the location of the plurality of in-transit units;and diverting the one unit to one of the destinations based on thediversion plan.
 41. A method as set forth in claim 40, furthercomprising the step of: communicating to a shipping carrier a diversioninstruction to divert the one unit to one of the destinations, thediversion instruction including a destination identifier correspondingto the one destination based on the diversion plan and a containeridentifier including enough information to locate the one unit on atransportation vehicle of the shipping carrier.
 42. A method as setforth in claim 41, wherein the transportation vehicle is a cargo vessel.43. A method as set forth in claim 41, wherein the transportationvehicle is a railroad train.
 44. A method as set forth in claim 41,wherein the transportation vehicle is a land transport vehicle.
 45. Amethod as set forth in claim 41, wherein the one unit has not beenallocated to any one of the destinations.
 46. A method as set forth inclaim 41, wherein the one unit was previously allocated to one of thedestinations.
 47. A system for providing estimated time of arrivalinformation to a client located on the network, comprising: means forpresenting to the client one or more pages adapted to elicit a productinquiry including a product number; means for receiving the productinquiry; means for determining a plurality of estimated time of arrivalsto a plurality of destinations for at least one in-transit unit havingthe product number; and means for transmitting to the client theestimated time of arrivals.
 48. A system as set forth in claim 47,further comprising: means for transmitting to the client diversionrecommendation information including recommended quantity of units ofthe product number to divert to at least one of the destinations, therecommendation information being based on inventory information andin-transit information, the current inventory information includingsales history and back-order data for the at least one destination, andthe in-transit information including a location for each of the at leastone in-transit unit.
 49. A system as set forth in claim 47, furthercomprising: means for presenting to the client one or more pages adaptedto elicit from the client a product diversion request including ashipping carrier identifier, a product number, a quantity number, and adestination identifier; means for receiving the product diversionrequest; and means for diverting one of the at least one in-transitunits to a final destination corresponding to the destinationidentifier.
 50. A system as set forth in claim 49, further comprising:means for diverting one of the at least one in-transit units based onthe results of a diversion planning processor adapted to processinventory information and in-transit information, the current inventoryinformation including sales history for at least one of the destinationsand back-order data on at least one of the destinations, and thein-transit information the location of at least one transportationvehicles carrying at least one of the in-transit units.
 51. A system asset forth in claim 49, further comprising: means for transmitting to theclient acknowledgement information including the product number and aquantity of units of the product number diverted to the finaldestination.
 52. A system as set forth in claim 49, further comprising:means for communicating to a shipping carrier a diversion instruction todivert one of the in-transit units to the final destination, thediversion instruction including the destination identifier and acontainer identifier including enough information to locate the producton a transportation vehicle of the shipping carrier.
 53. A system as setforth in claim 52, wherein the transportation vehicle is a cargo vessel.54. A system as set forth in claim 52, wherein the transportationvehicle is a railroad train.
 55. A system as set forth in claim 52,wherein the transportation vehicle is a land transport vehicle.
 56. Asystem as set forth in claim 49, wherein the one unit has not beenallocated to any one of the destinations.
 57. A system as set forth inclaim 49, wherein the one unit was previously allocated to one of thedestinations.
 58. A system for obtaining estimated time of arrivals froma server on a network, the system comprising: means for transmitting tothe server product inquiry information including a product number; andmeans for receiving a plurality of estimated time of arrivals to aplurality of destinations for at least one in-transit unit having theproduct number.
 59. A system as set forth in claim 58, furthercomprising: means for transmitting to the server a diversion requestincluding a shipping carrier identifier, a product number, a quantitynumber, and a destination identifier; and means for receiving anacknowledgement from the server that it has diverted one of the at leastone in-transit units to a final destination corresponding to thedestination identifier.
 60. A system as set forth in claim 58, furthercomprising: means for transmitting to the server a product purchaseorder including a product number, a quantity number, and a customeridentifier; and means for receiving an acknowledgement from the serverthat the product order has been accepted, wherein the server diverts oneof the at least one in-transit units of that product number to a finaldestination based on the customer identifier.
 61. A system for providingexcess freight cost information including excess costs for ordering fromat least one secondary warehouse, the system comprising: means forpresenting to a client located on a network one or more pages adapted toelicit a product inquiry including a product number; means for receivingthe product inquiry; means for receiving from a product weight tabledatabase a corresponding product weight; means for receiving from adealer location database a dealer address; means for receiving from afreight table database at least one freight cost based on the dealeraddress; means for calculating at least one difference in freight costbased on the information stored in the product weight database, thefreight database and the dealer location database; and means fortransmitting to the client the at least one difference in freight cost.62. A system for obtaining excess freight cost information includingexcess costs for ordering from at least one secondary warehouse from aserver located on a network, the system comprising: means fortransmitting to a server product inquiry information including a productnumber and a customer identifier; and means for receiving at least onedifference in freight cost for ordering from at least one secondarydestination.
 63. A system for automatically diverting one of a pluralityof in-transit units having a product number to one of a plurality ofdestinations, the system comprising: means for determining an estimatedtime of arrival to each of the plurality of destinations for theplurality of in-transit units; means for determining a diversion planbased on sales history information for each of the plurality ofdestinations, current inventory information for each of the destinationsand in-transit information, the current inventory information includingback-order data, the in-transit information including the location ofthe plurality of in-transit units; and means for diverting the one unitto one of the destinations based on the diversion plan.
 64. A system asset forth in claim 63, further comprising: means for communicating to ashipping carrier a diversion instruction to divert the one unit to oneof the destinations, the diversion instruction including a destinationidentifier corresponding to the one destination based on the diversionplan and a container identifier including enough information to locatethe one unit on a transportation vehicle of the shipping carrier.
 65. Asystem as set forth in claim 64, wherein the transportation vehicle is acargo vessel.
 66. A system as set forth in claim 64, wherein thetransportation vehicle is a railroad train.
 67. A system as set forth inclaim 64, wherein the transportation vehicle is a land transportvehicle.
 68. A system as set forth in claim 64, wherein the one unit hasnot been allocated to any one of the destinations.
 69. A system as setforth in claim 64, wherein the one unit was previously allocated to oneof the destinations.
 70. Computer-readable medium containing code forproviding estimated time of arrival information to a client located onthe network, said code including: code for presenting to the client oneor more pages adapted to elicit a product inquiry including a productnumber; code for receiving the product inquiry; code for determining aplurality of estimated time of arrivals to a plurality of destinationsfor at least one in-transit unit having the product number; and code fortransmitting to the client the estimated time of arrivals. 71.Computer-readable medium according to claim 70, said code furtherincluding: code for transmitting to the client diversion recommendationinformation including recommended quantity of units of the productnumber to divert to at least one of the destinations, the recommendationinformation being based on inventory information and in-transitinformation, the current inventory information including sales historyand back-order data for the at least one destination, and the in-transitinformation including a location for each of the at least one in-transitunit.
 72. Computer-readable medium according to claim 70, said codefurther including: code for presenting to the client one or more pagesadapted to elicit from the client a product diversion request includinga shipping carrier identifier, a product number, a quantity number, anda destination identifier; code for receiving the product diversionrequest; and code for diverting one of the at least one in-transit unitsto a final destination corresponding to the destination identifier. 73.Computer-readable medium according to claim 72, said code furtherincluding: code for diverting one of the at least one in-transit unitsbased on the results of a diversion planning processor adapted toprocess inventory information and in-transit information, the currentinventory information including sales history for at least one of thedestinations and back-order data on at least one of the destinations,and the in-transit information the location of at least onetransportation vehicles carrying at least one of the in-transit units.74. Computer-readable medium according to claim 70, said code furtherincluding: code for transmitting to the client acknowledgementinformation including the product number and a quantity of units of theproduct number diverted to the final destination.
 75. Computer-readablemedium according to claim 70, said code further including: code forcommunicating to a shipping carrier a diversion instruction to divertone of the in-transit units to the final destination, the diversioninstruction including the destination identifier and a containeridentifier including enough information to locate the product on atransportation vehicle of the shipping carrier.
 76. Computer-readablemedium according to claim 75, wherein the transportation vehicle is acargo vessel.
 77. Computer-readable medium according to claim 75,wherein the transportation vehicle is a railroad train. 78.Computer-readable medium according to claim 75, wherein thetransportation vehicle is a land transport vehicle. 79.Computer-readable medium according to claim 72, wherein the one unit hasnot been allocated to any one of the destinations.
 80. Computer-readablemedium according to claim 72, wherein the one unit was previouslyallocated to one of the destinations.
 81. Computer-readable mediumcontaining code, said code including: code for transmitting to theserver product inquiry information including a product number; and codefor receiving a plurality of estimated time of arrivals to a pluralityof destinations for at least one in-transit unit having the productnumber.
 82. Computer-readable medium according to claim 81, said codefurther including: code for transmitting to the server a diversionrequest including a shipping carrier identifier, a product number, aquantity number, and a destination identifier; and code for receiving anacknowledgement from the server that it has diverted one of the at leastone in-transit units to a final destination corresponding to thedestination identifier.
 83. Computer-readable medium according to claim81, said code further including: code for transmitting to the server aproduct purchase order including a product number, a quantity number,and a customer identifier; and code for receiving an acknowledgementfrom the server that the product order has been accepted, wherein theserver diverts one of the at least one in-transit units of that productnumber to a final destination based on the customer identifier. 84.Computer-readable medium containing code for providing excess freightcost information including excess costs for ordering from at least onesecondary destination, said code including: code for presenting to aclient located on the network one or more pages adapted to elicit aproduct inquiry including a product number; code for receiving theproduct inquiry; code for receiving from a product weight table databasea corresponding product weight; code for receiving from a dealerlocation database a dealer address; code for receiving from a freighttable database at least one freight cost based on the dealer address;code for calculating at least one difference in freight cost based onthe information stored in the product weight database, the freightdatabase and the dealer location database; and code for transmitting tothe client the at least one difference in freight cost. 85.Computer-readable medium containing code for obtaining excess freightcost information, said code including: code for transmitting to theserver product inquiry information including a product number and acustomer identifier; and code for receiving at least one difference infreight cost for ordering from at least one secondary destination. 86.Computer readable medium containing code for automatically diverting oneof a plurality of in-transit units having a product number to one of aplurality of destinations, said code including: code for determining anestimated time of arrival to each of the plurality of destinations forthe plurality of in-transit units; code for determining a diversion planbased on sales history information for each of the plurality ofdestinations, current inventory information for each of the destinationsand in-transit information, the current inventory information includingback-order data, the in-transit information including the location ofthe plurality of in-transit units; and code for diverting the one unitto one of the destinations based on the diversion plan. 87.Computer-readable medium according to claim 86, said code furtherincluding: code for communicating to a shipping carrier a diversioninstruction to divert the one unit to one of the destinations, thediversion instruction including a destination identifier correspondingto the one destination based on the diversion plan and a containeridentifier including enough information to locate the one unit on atransportation vehicle of the shipping carrier.
 88. Computer-readablemedium according to claim 87, wherein the transportation vehicle is acargo vessel.
 89. Computer-readable medium according to claim 87,wherein the transportation vehicle is a railroad train. 90.Computer-readable medium according to claim 87, wherein thetransportation vehicle is a land transport vehicle. 91.Computer-readable medium according to claim 87, wherein the one unit hasnot been allocated to any one of the destinations.
 92. Computer-readablemedium according to claim 87, wherein the one unit was previouslyallocated to one of the destinations.